Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/gnu/objcissu.lha/messages-to-nil

Text File | 1993-03-01 | 7KB | 177 lines

From: Patrick Rusk <[e-mail]>
Date: Thu, 12 Nov 92 16:43:46 -0500
To: [e-mail]
Subject: GNU Objective-C suggestion

Geoffrey,

I just spent a good bit of time looking up a bug that resulted from a
message being passed to "nil" and not causing an error. I would like
to recommend that the GNU Objective-C runtime work differently. It
should have a nil object that has methods to respond to errors like
this. Perhaps the default error handler should be to ignore the errors
like NeXT Objective-C does, but the opportunity to bomb out should be
given.

-- Pat

Return-Path: <[e-mail]>
Date: Tue, 16 Feb 93 16:48:00 -0500
From: [e-mail] (Richard Stallman)
To: [e-mail]
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]> (message from Kresten Krab Thorup on Tue, 16 Feb 1993 22:20:23 +0100)
Subject: gnu objc runtime

    a considerably number of bugs, and introduced some features like
    optional handling of messages send to nil, and much better
    initialization of the system.

It occurs to me that this feature might interfere with the goal of making
method lookup faster and open-coding it.  If so, then it is important
*not* to have this feature.  If people start using it, they will be unhappy
when it is taken out.  And it is not a very important feature.

Have you read the file of ideas that comes with the runtime?

Return-Path: <[e-mail]>
Date: Wed, 17 Feb 1993 01:19:29 +0100
From: Kresten Krab Thorup <[e-mail]>
To: [e-mail], [e-mail]
Subject: gnu objc runtime

Stallman writes:

  [Concerning sending messages to nil i guess...]
  It occurs to me that this feature might interfere with the goal of making
  method lookup faster and open-coding it.  If so, then it is important
  *not* to have this feature.  If people start using it, they will be unhappy
  when it is taken out.  And it is not a very important feature.

  Have you read the file of ideas that comes with the runtime?

Yes I did read the file of ideas, and most of the ideas are
incorporated into my runtime system.  The handling of messages to nil
isn't expensive, actually my objc_msgSend looks like this:

    extern Class_t nilClass;

    if(receiver != nil)            /* send msg to reciever */
      return get_imp(receiver->class_pointer, sel);

    else                /* otherwise send it to nil */
      return get_imp(nilClass, sel);

Now, if the message happens to be send to `Nil' it is caught by
-doesNotRecognize: in that class, which can then choose to ignore the
message or issue an error.  OK, This is a bit more expensive if
someone sends a terrible lot of messages to NULL pointers, but who
would ever call that good programming style anyway?

[...moved...the matter of initialization...]

Return-Path: <[e-mail]>
Date: Wed, 17 Feb 93 00:22:01 -0500
From: [e-mail] (Richard Stallman)
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Kresten Krab Thorup on Wed, 17 Feb 1993 01:19:29 +0100)
Subject: gnu objc runtime

      The handling of messages to nil
    isn't expensive, actually my objc_msgSend looks like this:

    extern Class_t nilClass;

    if(receiver != nil)            /* send msg to reciever */
      return get_imp(receiver->class_pointer, sel);

    else                /* otherwise send it to nil */
      return get_imp(nilClass, sel);


Please take this out.

It is clear that you didn't get the point.  I want this function to be
*open-coded*.  That means we have to eliminate almost everything now
in it.

Adding a new statement, even something that seems simple,
is going in EXACTLY the wrong direction.

Just because something sounds like a feature DOES NOT mean
it is a good idea!

Return-Path: <[e-mail]>
Date: Wed, 17 Feb 93 14:15:16 -0500
From: [e-mail] (Richard Stallman)
To: [e-mail]
To: [e-mail]
In-Reply-To: <199302171615.AA00184@carrara> ([e-mail])
Subject: gnu objc runtime

It is possible that there is some really important reason not to open-code
the dispatcher.  For example, there could be a feature that *users want
very much* that is incompatible with open-coding.  I could easily not know
about it, since I am not an Objective C user.

However, a feature added just because it seems possibly neat is not enough
of a reason.  Neither is something used for internal purposes if there is
a way to avoid the need for it.

This is because open-coding will make dispatch significantly faster,
and I know users will like that.  It will make it feasible to use
messages for smaller things.

Return-Path: <[e-mail]>
Date: Wed, 17 Feb 1993 21:27:59 +0100
From: Kresten Krab Thorup <[e-mail]>
To: [e-mail], [e-mail]
Subject: gnu objc runtime
Cc: krab.It.is.possible.that.there.is.some.rea[e-mail],
        there.could.be.a.feature.that.*users.want.very.much*.that.i[e-mail],
        [e-mail],
        a.feature.added.just.because.it.seems.possibly.neat.is.not.enough.of.a.reason.Neither.is.something.used.f[e-mail]

The only good reason I could think of was for having a special
messenger used during initialization, but if forwarding is possible it
should not be needed as far as I can see.

   This is because open-coding will make dispatch significantly faster,
   and I know users will like that.  It will make it feasible to use
   messages for smaller things.

Another approach than the forwarding one I just send you, is to have
the messenger look like this:

   IMP
   objc_msgSend(id receiver, SEL selector)
   {
     if (__objc_alternative_msgSend != 0)
       return (*__objc_alternative_msgSend)(receiver, selector);
     else
      <do normal selector here>
   }

This will only cost a single fetch/branch instruction to perform, and
it could easily be inlined by hardcoding it into gcc (I assume that is
what open-coding means?).

/Kresten

Return-Path: <[e-mail]>
Date: Wed, 17 Feb 93 15:40:35 -0500
From: [e-mail] (Richard Stallman)
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Kresten Krab Thorup on Wed, 17 Feb 1993 21:27:59 +0100)
Subject: gnu objc runtime

Each additional thing that the message lookup has to do means a few
additional instructions for *every* message send.

It may be *possible* to open-code it with the extra indirection.  I
don't want to!  Stop exploring that possibility and look for a way to
*get rid* of the extra indirection.